Thank you for watching.
Thank you for watching.
Thank you for watching.
Thank you for watching.
Thank you for watching.
Thank you for watching.
This is a logic developed, again, from the various active voice fingerprinting system methods I have discovered using my research.
XPROB is a tool that actually was released at Black Hat two days ago, and it is available from our website.
It was written along with Fyodor Yurkin.
He's from the Snore Development Team.
He's not the same Fyodor from NMAP, so there are different Fyodors in the world, I guess.
The tool automates X.
It's version 0.0.1.
It works.
I'll talk about the limitation later and what will be the future.
The logic and the, well, the tool is simple, fast, and efficient, which I think every tool should be.
It's still a proof of concept.
And in the future, this tool will have some kind of artificial intelligence and failover mechanism.
Say, you started scanning using some mechanism.
And you failed.
It will failover automatically to another logic.
And eventually, it will intelligently identify the operating system.
The problem with some tools today, especially the open source one, when you do scanning,
is sometimes you get inaccurate and inconsistent results.
And I'll show some examples.
This is true especially with Windows-based operating systems with TCP.
And I will be showing examples with NMAP, for example, and how X can solve this thing.
So basically, it all depends where you sit.
If you are a penetration tester, you sit inside an internal network.
You want to see which operating system you have.
This is one thing.
If you are an attacker and you sit outside somewhere in the Internet,
say, outside.
If you are outside of a firewall, sit here, this is another thing.
So you may be having to use some different protocols or some different probes or some different techniques.
It depends where you sit.
Sure, it depends on the firewall and what it lets in.
But eventually, you'll need to use something intelligently.
For example, if you have a firewall, you will not expect to see traffic flying in for years.
Or UDP ports, which are not used on targets inside the internal networks.
Or you will be filtering heavily, if you are doing it good.
But if you are inside a network, it changes the picture.
And usually, between internal segments, you can use ICMP.
Because management or IT management need to see the availability of operating systems.
Because they are lazy to get their fat asses.
Because they are lazy to get their fat asses. Because they are lazy to get their fat asses.
So they can go up from the seats and go up to Mrs. Robinson up in the 9th floor, just to see she plugged off her Ethernet cable.
So they can go up from the seats and go up to Mrs. Robinson up in the 9th floor, just to see she plugged off her Ethernet cable.
About the license.
License in GNU, the code is available.
But all material is for non-profit educational use only.
So if you want to use this for commercial stuff, you need to talk to me.
If you guys want to use that and you're not using it for...
commercial usage, and if it's education, you can download it from our website.
Again, the tool uses one to four packets, and I'll show you how it does it.
Okay, the logic starts with a UDP datagram sent to a definitely closed UDP port.
I send some data inside the data portion of the packet.
It is up to 70 bytes of data inside the offending packet.
Why definitely close UDP port?
It's definitely closed so I can get the port unreachable.
So how can it definitely close UDP port?
One of the examples will be go to the analyst for assigned ports
and get yourself something.
And then randomly, when you use the tool, use random ports that eventually need to be closed.
Now, a closed UDP port sends you a port unreachable.
If you don't get the port unreachable, you understand there is a firewall filtering you,
and you may failover to another logic.
We will see an example when we will talk about Windows-based operating systems.
Jeff Moss let me play with DAFCON.org.
So you can see how I can do failover.
And identify DAFCON.org using a failover mechanism.
So we have a way to identify firewall presence.
And if we receive back a reply, we play.
We will be using a nice fingerprinting thing with some operating systems and networking devices.
When they send an error message, they send the preceding bits,
which is part of the type of service byte, as you can see here,
set to the value of six decimal, which is C0 hex.
This means that Linux play the role of a router, like RFC 1812 states,
that router has to do.
Well, I don't know why Linux does that,
but if we want to differentiate between Linux Grinnell 2.0, 2.2, 2.4,
and Cisco routers and extreme network switches,
we will look at echoing integrity problems inside the echo data.
I don't know how many of you know, but with an ICMP error message,
certain amount of data from the offending packet is getting echoed back with the error.
So you can understand which packet caused the error.
The IP header and at least eight data bytes are echoed back.
There are some operating systems and networking devices that will echo more.
For example, we have here Linux.
We'll see that in the next slide, that echoes nearly everything that we'll give him.
And on the other hand, we have Cisco and extreme networks that echoes only eight data bytes.
So basically, using another internal test, not a test that I need to repeat,
I can differentiate between the Linux bunch and the Cisco and extreme network bunch.
If I want to differentiate furthermore between Cisco and extreme networks,
I can look at the UDP checksum header for the header.
With the extreme networks, it will be zero.
With Cisco, it will be echoed correctly.
So basically, using one datagram, I'm able to identify Cisco routers using iOS 11X with 12X
and extreme network switches.
If I look at the Linux bunch,
I will be defining it according to the IP time to refill value.
Linux 2.0 uses 64, the others using 255.
And using another query, which makes two queries to the Linux 2.2 and 2.4,
I can look if we are having IPID set to zero,
which is a common problem with IPID with Linux 2.40 to 2.44.
And therefore, I can differentiate between Linux kernel 2.2 and 2.45
to Linux kernel 2.40 to 2.44.
So using only two datagrams, I was able to get Linux 2.2 Xs and 2.4 Xs.
Using one datagram, I was able to get the Cisco, the extreme networks, and the Linux 2.0.
Now, if you look at the real world example,
look here.
It's a real IP.
Port scanning is legal.
And I would like to thank Jennifer Granik for the legal advice.
Yeah, well.
We can see the first query.
First parameter to check is the preceding bits set to C0 here.
We can see that the data portion,
well, the data echoed.
Sorry, it's a mistake here.
No, sorry.
This is the data echoed really from this point.
We can see that everything that was sent inside the data portion of the offending packet got echoed here.
And you see the time to leave is 2.55.
So we basically differentiate it as 2.2 or 2.4.
And we send another ICMP echo request.
The IP ID is not 0.
Then this is 2.2 X or 2.45.
Now, we'll use a foobar, right?
You'll not believe me.
So this is redhat.com.
And now I might be getting more acceptance.
Wait until you see the Chinese sites.
This is actually X running.
You can see first test here, first test here.
All the trees are like internal tests that I showed you before.
And it identifies at 2.2 X or 2.45.
Now, if I use Nmap, I get the same results.
I get more packet sent, 3 seconds.
And I get 2.2 X, 12 to 2.2 X, 19.
Here, I was using, if you look closely, nearly 300 milliseconds to get the same results.
So if we go back now to the main branch
of the tree, we can now look at another parameter.
How much echoing data is given with the error message?
We have three groups.
The groups that echo back eight data bytes,
a group that echo only 64 by default,
and a group that echo everything.
Here is Linux.
He echoes everything like the other networking devices and boxes here.
But we identify it again.
This is like,
if we have some kind of a shaping,
a traffic shaping device,
and he plays with the preceding bits,
and if he fails to identify Linux in the first stage,
then it will identify Linux here as well.
Let's look at the main branch here,
at Sans Solaris, HPUX, and Mac OS.
Again, very simple test to differentiate between them.
And if you didn't know that,
Mac OS 7 X to 9 X acts like HPUX 11 X.
So they both bought the TCP IP code,
I guess, from the same company.
Not wise thing to do.
I was able to play with Mac OS 9 1 at Black Hat,
and I would like to thank Chris from Seagate
for letting me up using his box.
Now, if I'm having false results here,
if the timestamp here is blocked on the Sans Solaris,
sure, it will be identified as HPUX 11.
Still, it's just 0.0.1.
So in the future, we'll have better firewalling tests
with other queries as well.
Here is an example with Sans Solaris 2.7.
We can look.
Here is the offending packet.
Here is the error message.
We don't see the preceding bits here,
so we are at the main branch.
The data portion echoed, if you count the 58s,
it will give you 56,
and here is the UDP header, another 8 data bytes,
give you 64.
If you now look at the second packet sent,
you see that, again, I get timestamp reply,
so it was identified Sans Solaris 2.3 to 2.8.
To play really cool tricks with other printing systems,
I'm using echoing integrity problems,
mainly using some fields inside the IP header.
I have a couple of fields I can play with.
I have the IP total length field value,
which sometimes might be with 20 bytes less
or 20 bytes higher than the original.
IP ID, because of bit order problems, might be flipped.
The IP header checksum might be miscalculated or zero.
The 3-bit flags and offset field values,
if I set the DF bit with my request
or with my offending packet, it might be flipped,
so I might be seeing an error message
stating I sent a fragmented thing and get the error for,
so we'll see how we can use that.
And the UDP checksum might be miscalculated or zero.
As you can see, we have a lot of power methods to work with,
so how can we use that to slice and dice this correctly?
The first power method we will be using
is the IP total length field value.
Here we can see that we have three groups.
The one that echoes the field value with 20 bytes higher
than it was in the original.
Here it's less with 20 bytes, and here it's okay.
Let's look at the AIX machines.
We can see that we have here AIX-BSDI,
older NetBSDs, and Mac OS X Server.
Well, if you think about them,
they are all sharing the same base,
code at least the BSD and NetBSDs in Mac OS X.
They're all using the same base code for TCP IP.
Again, using some echoing integrity checks,
we can differentiate between the AIX machine here,
which miscalculated the IP header checksum,
to the other operating system,
which just sends zero here as the IP header checksum,
and differentiate between this group a bit more,
having one group with little end-to-end problems
and the other group with big end-to-end problems.
Again, this is only one packet sent,
and you can get a range of networking devices,
sorry, operating systems that are using
the same base TCP IP code.
After you send one packet, you get the results.
Here we might have more networking devices,
but the reason I didn't include them,
it was like your grandmother's printer from 1985
so if you really know what your target is,
you'll understand that if you're targeting
host or networking devices,
and in the future we'll add everything up.
So if you look again at the example,
it's not a real world, but I have more of these,
sent against an AIX 3.2 base machine,
see one query sent, a UDP query,
got the error message,
check for the IP total length,
got the base groups of operating systems,
got the IP header check,
got it miscalculated, got an AIX,
well, how much time was used?
290 milliseconds to get the results,
one packet sent, just processing the reply,
and I get the operating system.
So you can see here, proceedings checked,
amount of data bytes echo checked,
IP total length field checked,
the echoed value 118,
and it was only 98,
so one packet, 290 milliseconds,
you get AIX.
Someone got any question until that point?
Until this point?
Yeah.
The implementation is publicly available, yeah.
So here's a way how we can identify
OpenBSD 2.6 to 2.9 quite easily
with one packet as well.
From 2.6 with OpenBSD,
the IP total length echoed is less
with 20 bytes than the original.
I don't know why they are doing it,
but it's a problem.
There are some other reporting systems
and networking devices doing so.
We look at another echoing integrity check.
Here's the UDP checksum checked again.
We get here NFR IDS appliance,
which basically is OpenBSD with some minor changes.
It echoes the UDP checksum badly.
We can identify it here.
We have basically two reporting systems here,
which can we do another echoing integrity test
and get the OpenBSD 2.6 to 2.9 quite fast.
So if we look at another example,
we can see that, again, one test here
and some internal test for the reply I'm getting.
So pretty fast, I'm getting OpenBSD 2.6 to 2.9.
Here is the example.
310 milliseconds after sending the request,
I get the reply.
You can see proceeding zero.
Amount of database echoed here.
IP headers checksum.
And UDPR correct.
And the only parameter which is bad
is the total length field value.
So again, gives you pretty fast,
gives you the OpenBSD 2.8 to the group of 2.6 to 2.9.
So I was looking to do other tests
with some good methods.
Again, one good method is 3-beats flags
and offset field value.
Set it to a certain field value to flip between them
with 3-BSD 2.2x to 4.1
and NetBSD 1.3x group.
For example here,
if we are going to check what will be done here,
you can see that this group will flip the beat order
and ULTRIC just sends zero.
We can see a demonstration here.
It's a 3-BSD 4.0 machine.
We send one datagram.
It passes all our checks.
We see that the frag beats are flipped
and we are doing another internal test
which basically involves
looking at the IP header checksum echoed
which is zero with all 3-BSDs
and we get 3-BSD very fast.
Again, 350 milliseconds.
One packet sent.
Internal test.
And you get 3-BSD 2.2x to 4.1.
Basically your reply,
with your reply it's like looking at
a fragmented packet you have sent
with your offending packet.
What this basically was,
the DF bit was set here,
it was flipped,
so it's parsed differently with the TCP dump.
Now this is what causes the UDP checksum,
sorry, the IP header checksum to be bad as well
if you can see it from the TCP dump trace.
So until now,
we just quickly went through the
most basic Unix operating systems.
We saw that with one or with two packets
we are able to identify
pretty fast operating systems.
Just as a reminder,
this is also automated with a tool.
Now I needed an ultimate test
to differentiate between Microsoft-based operating systems
to Unix-based operating systems.
This was actually my first post-bug trick
about ICMP stuff.
What happens with Microsoft-based is
if you set the code field,
there are type field and code field,
which defines the type of ICMP message
you are sending or receiving.
If you play with the code field
and you send a field value,
which is different than zero,
with your request,
with your ICMP echo request,
the reply with Microsoft-based operating systems,
will set this field to zero.
Now the RFC states
that you only have to change the type,
recalculate the checksum
and send the error message back.
Well, I guess at Microsoft,
they wanted to play God,
so they changed that to zero
and sent back the echo reply.
So we are able to identify
each and every Microsoft-based operating system
according to this code field
and this little fingerprinting mechanism.
I loaded up another test with it,
which uses preceding bits.
I will refer to it a bit later,
and the DF bit.
Let's look at the Microsoft branch.
After understanding from the ICMP echo reply
that this belongs to Microsoft,
I have some unique tests
identifying this.
We'll look at the IPTTL.
With Microsoft Windows 95,
they are using 32 as the default field value
for that field.
When they send the echo reply,
it is unique between the Microsoft-based operating systems,
and others are using 128.
Now you will remember,
I put the value inside the preceding bits
with my ICMP echo request.
What will happen is,
that there are some operating systems
that will not echo back my preceding bits,
which I have set it with my request.
What will happen is,
guess what,
Microsoft Win2K,
SP1 and SP2
will not echo this field value.
So what will happen,
it will allow us to identify
Win2K versions quite easily,
just after two packets sent,
looking at the TTL,
looking at the code field,
TTL, preceding bits are zero,
here we go,
with Win2K after two packets.
The other Microsoft-based operating system,
which are the older one,
and I'm not referring to
Microsoft Windows for work groups,
95,
sorry, 98, 98SE,
ME, NT,
SP3 and less,
and NT4,
NT,
sorry, NT4, SP4 and above
are here.
So we can differentiate between them as well,
but let's look at the example with
Win2K.
This is a real world example with
Win2K SP2.
You can see here,
proceedings checked,
amount of data echo checked,
total length is fine,
and we play another,
we check another criteria here,
the DFB is not echoed at all
with our reply,
and is not flipped,
here you can see that.
So,
basically,
we need to send another packet.
If we're now sending it,
you can see,
where is that?
Here,
that I set a certain field value
inside the code field,
and I got back zero,
and I set a certain field value
for the proceeding bits,
here it says hex,
and I didn't,
well,
I didn't see it back with the reply,
it wasn't echoed.
So,
this was wimbledon.org.
I wanted to see Anna Kournikova.
So,
I went to wimbledon.org,
yeah,
go tennis,
and this is what I got,
using Win2K,
up there.
Here you can see,
the actual,
hex running on wimbledon.org,
two tests,
all the internal tests,
gets you Windows 2K,
pretty fast.
If we do BannerGraph,
just to prove you guys,
that this is,
Windows 2000,
here you get,
a great application running there,
called IIS 5.0.
Just type,
go tennis,
couple of enters,
and you get that.
So,
I wanted to differentiate between,
the entire group of Microsoft-based
operating systems.
Basically,
we're all dependent here,
upon,
replies,
we are getting,
from our hosts.
As you will see,
in the next,
two examples,
well,
they give us what we need.
Here,
we send an ICMP timestamp request,
differentiated between,
two groups,
the NT4,
and 9898SE and ME.
For another address mask,
I am able,
with a reply,
to identify 9898SE and ME,
which does not reply.
With the second address mask,
for the NT box,
I am able to differentiate between,
NTSP3-
and NTSP4+.
So,
let's see some examples.
Skip.
Okay.
Let's see that,
that example,
I will not skip it.
I have four tests here,
as you can see,
and,
internal logic is being used here.
Identify the,
Microsoft Windows,
family TCP IP stack,
and gives me,
NTSP4+.
As you can see from the trace,
this is again,
I'm looking,
I see that I don't qualify,
for any of the tests I'm using.
I'm using an echo request,
set the code to 123,
get the code zero,
set the type of service to six,
get the type of service back,
this means this is not,
Win2K machine.
Sending a timestamp request,
an address mask request,
doesn't get any reply,
so this is,
WinNT4,
SP4,
and above.
So,
if you guys will not like my talk,
I might join the,
French Foreign Legion,
and ran away for a couple of years.
So,
if you just look at what I got,
after I type,
www.frenchforeignlegion.org,
I got a nice error message,
.asp,
well,
guess what this is.
If you give us your name,
and email address,
we might call you for duty.
Okay, yeah, right.
So,
here is actual screenshot.
You can see X running on my box,
French Foreign Legend,
running Windows,
Nt4,
SP4,
and above.
Now,
if you don't believe me,
this is Nmap.
I was trying to do OS fingerprinting,
and give actually Nmap,
an open port,
that I can tell Nmap,
to use less traffic initiation,
to identify that machine.
But, guess what?
This didn't help in this case,
and I didn't get anything back.
So,
I was actually telling Nmap,
okay, do whatever you want to.
And here,
after,
1500 packets,
after,
I can get,
basically, problematic results,
as you can see.
Nt4,
or Win95,
or Win98,
or WinNt4,
SP3,
or WinNt4,
server,
SP5,
and the hotfixes.
This is not accurate,
but,
if I can,
for example,
this is a good example to understand,
that if we can tell the tool,
that we are going to a web server,
then port 80 is open.
I don't need it to port scan the operating system,
if I, for example,
want to use an IIS exploit.
Right?
So,
I told you I'll get to DEFCON.org.
Thanks to Jeff for letting me do that.
I like to design.
DEFCON.org,
basically, what it gives me,
is the ability to show you why I need a failover mechanism.
Well,
because I'm sending a UDP datagram
to the source port,
and I need the ICMP port unreachable,
Jeff kindly closed down the UDP stuff.
I want to thank him for giving me hard life here.
But,
if I'm just using the Windows portion of the tree,
as a query-only mechanism,
this means that,
let's go back a bit,
if, for example,
I start and use the,
yeah,
I've been here,
I send the code field set to zero,
set to a value different than zero,
and I get a reply with the code zero,
and I can play only with the Microsoft base tree.
Now I have to get back.
Oh, I didn't think it's frightening the kid.
Okay.
I'm struggling here.
Okay.
So,
if I'm doing the same tests,
I'm able to state
that Mr. Moss is running NT4SP4 and above,
and it actually was,
shut up,
and it was actually cross-referenced with Jeff.
Yeah, if you try to play on that website,
you'll have to deal with me.
So,
as a courtesy to Jeff,
here are the traces.
You can see code field is not echoed.
Proceedings are echoed,
so basically it gives you
the other Microsoft-based operating systems.
It doesn't answer timestamp requests
or address mask requests,
which are allowed on the box,
and this is NT4SP4 and above.
This is Nmap.
Again,
trying to give Nmap a port to work with,
and it gives me WinNT4,
Win95,
Win98.
Trying to,
not to give any port,
and it generates
in
two minutes here
this result.
Well, you saw that before.
So basically it's,
sure it tells me it's Windows,
but it doesn't let me understand
what is the Windows box I'm attacking
or probing or auditing.
So,
we can do a lot of stuff more than that.
If we're going back to the main branch,
we can do a lot of other tests.
I have set the DF bit inside the echo request,
and I'm expecting several operating systems,
when they generate the ICMP echo reply,
to put the DF bit there,
even though if they are not usually doing so.
This means that if I send the ICMP echo request
without the DF bit,
the DF bit will not be set with the reply.
So there are some operating systems
with just, you know,
flip around the,
you know,
IP addresses,
do their recalculating,
change the type,
recalculate checksum,
and send back the results.
There are some other operating systems
which are more intelligent
and will build up a new packet.
I don't know if Novell or WorldTreex
are that intelligent,
but here they didn't echo the DF bit,
and we are able to identify them both
because of the TTL.
We can do other tests like this.
With the error with the DF bit
and identify NetBSD,
the newer versions,
and 2.4, 2.5 OpenBSD,
and older OpenBSD as well.
So basically this is still,
here is two packets.
With the NT4 stuff,
it was up to four packets.
With Win2K, it was two packets.
With Win95, it was two packets.
So very small amount of packet sent,
and you see how fast the replies getting back
and the calculation is being done.
If I'm still on the main branch,
I can send an ICMP information request
and try to identify DGUX, for example,
different DGUXs,
HBOX, 10X, and OpenVMS.
I will not go through that
because you all can read that from my website.
I want to show the examples.
Now, this is example with DGUX 5.6.
We have three datagram sends here.
One is UDP, close port,
ICMP echo request with various tests
and information request,
which is get a response for that,
and we can see another test
and gets it as a DGUX.
Again, we do our magic here,
and here,
and here,
and here,
and here,
and here,
and basically get the results.
It's 632.
Yeah, basically 600 milliseconds
after three packets sent,
all the process on the replies.
So 600 milliseconds to get DGUX 5.6.
So the rest of the three,
so I can say I cover FreeBSD 4.125,
might be unreliable according to our target.
If we are targeting an operating system
and we know that we are targeting an operating system,
for example, if we target,
well, our next nice example
would be a known website,
we know that we are not targeting
a networking device,
which might be giving us false results here.
So basically if we will follow the logic here
and here,
we will be might able to look at the FreeBSDs now.
If you didn't know,
FreeBSD 5.0 changed its IPTTL field value
with the replies to 64.
Guess some didn't know that.
So you all know Nessus, right?
Who doesn't know Nessus?
Okay.
This main Nessus site.
Basically what the tool gives me here
is that I checked all the logic
and this is some kind of a Unix.
The logic goes and stops at that point
because of accuracy problem with the networking devices.
Now if you look closely
at what we have received back,
we can see that
we have the UDP header checker
checksum set to zero here
and the time to live 64
was set to 64 initially here.
Now if we go to the logic,
we can see that the IP header was okay,
the IP ID was okay.
We go down,
the UDP checksum header was zero
and the TTL was 64,
so it needs to give us FreeBSD 5.0 now.
This is Nmap.
I guess it needs to insert the TTL thingy.
It gives us FreeBSD 4.3.
Questions until this point?
No questions.
Yeah.
To have this example working,
I have it's hard coded,
but 0.0.2.
which is scheduled soon,
will have its own fingerprinting database
and a logic that will work dynamically
with some nifty tricks in the database.
So what we'll have to do only is to
put more fingerprinting inside a tool
and run it independently.
Sure.
So people can send me fingerprints.
Yeah, well if you'll be at the end of the slides,
there is slides about this.
Thank you for reminding me this.
So I was thinking what websites
can be interesting for myself to look
and might interest you guys.
I went for one of
the American favorite nations.
The nation that deny of service,
the Navy.
China.
So,
in order to look what is so good in China,
and to see if they need some thick guys,
I went to
the Communist Party newspaper.
I went to
People's Daily.
Now, what is so nice about the Chinese newspaper
is that everything is so cool in the world.
Here you see Chinese NBA player
doing some good stuff,
and all the news are so good,
and everything is cool,
so cool in the world.
Okay.
So I sent, I fired away X
on People's Daily.
One packet got me back
People's Daily using OpenBSD
something between 2.6 to 2.9.
Okay, they weren't wise enough
to use OpenBSD,
but why not firewall UDP?
You can see here
why this traced back to OpenBSD.
The IP total length field value
is 20 bytes less than it was
with the offending packet,
echoed 20 bytes less,
and the other fields are okay.
So this is OpenBSD 2.6 to 2.9,
one packet sent,
and you see the link to China.
Man.
I now understand why they
denial of service in the Navy.
This is,
look at how many milliseconds
it took, like 360 milliseconds
it took the reply to get back,
and for me to identify
peoplesdaily.com.cn.
So, after looking at the news,
newspaper,
I was thinking,
if it's so damn nice,
let's get us something cool at Beijing.
Why not buying some mics?
The microphone store in Beijing.
But before that,
tried to do the same thing with Nmap,
failed.
Nine minutes after,
didn't get any results.
So, it shows you that sometimes,
it's not good enough,
and we need to fail over,
or use something else.
So, I went to Beijing,
Seven Iron Audio.
I wanted that mics, man.
So, there is a,
some kind of a microphone here,
dynamic microphone,
wireless microphone,
and other pro audio devices
out of Beijing.
So, I bet they have some kind of
online orders form.
I went and tried to identify
what it ran on,
and gave me a Linux 2.2 or 2.4.
Two packets here,
you can see.
Very nice,
I mean,
for a audio shop.
Here is the same results
with Nmap,
gives the accurate results.
But again,
the amount of packets I have to invest
in order to get the results
is about 1,500
if I don't specify the open ports.
It was so damn nice.
I was so satisfied
with the microphones.
So, I wanted to buy myself a car.
I mean, the car,
carguy.coms.cn.
Why don't we have a Ferrari here?
We have this engine car.
I don't get it.
But there was a
super awesome cool animation here
that you don't see.
That gave it away as a...
You'll see what it is.
As a Microsoft Windows NTSP4 Plus based box.
The animation was so ugly,
so I spare you.
Four packets,
sent really fast.
Identified as WinNTSP4.
Here again,
sorry for the comparison with Nmap,
but it's the tool
that nearly everybody uses.
Here again,
I get several results
which the tool is not able to identify
different TCP stuff
between Microsoft-based operating system.
It's not just Nmap,
it's other tools that are based on TCP only.
Nearly TCP only stuff.
After I was so dissatisfied
with my car,
I went to buy a trailer.
Look at that trailer.
Awesome trailer.
So I didn't understand anything,
but I bet they need you
to deposit something
before you buy something.
So,
ChinaTrailer.com
uses Linux 2.2 or 2.45.
Again,
pretty fast.
You have to send two packets
and you get the results.
This is accurate results,
takes more time,
more packets invested.
What is so nice with...
This is my train stuff.
What is so nice with X,
you basically are very stealth
because you don't understand
what the hell hit you
and you cannot understand
that you've been mapped.
And now,
if in the future this is planned,
I will add like
real data portion information
of a real application
say I identify DNS service
of the organization,
I know where they are,
and I send this offending packet
to UDP53
and I steal some code
from Manus Lookup
and I do lookups
and send them to the IP address
which is my target.
So,
what are the admins might say?
Oh, look at that retards group kitty.
Thank you, guy.
I just mapped you.
I don't need anything back from you.
So,
adding some real world
data portion to these scans
might do much more stealth stuff
and if you can play with the...
You say,
I want to send my UDP stuff
with this and that application
or randomize that,
nobody will understand
what you are doing.
So,
after I was so satisfied
with my trailer,
I went to buy a train.
Up in Mongolia,
there is a website called
im1mgt.com.cn
which basically bids you,
builds you a train.
I was so impressed.
Running on Win2K,
SP1 or SP2.
Again,
two packets in,
I get the Win2K identifier.
Well, look at that.
You want to buy a train
or you want to owe the world?
If you look down,
this is quite amazing
because hey,
we are running Black Eyes here.
And we are ultra cool
with all these open ports.
We have FTP,
HTTP,
HTTPS.
We play Doom here, man.
Does your management know that?
So, basically,
I tried to map this
websites with Nmap as well.
I guess I'll chat with Fyodor
about giving some other kind of
intelligence inside Nmap
so we can easily identify
some Microsoft-based operating system
because if you are using
the default thing with Nmap,
it sends echo requests.
So, if we play with some parameters,
I might be doing that a bit better
and we can have the results better.
So, here you can see
that this is IIS 5 Win2K.
So, you can just believe me
that it is the train stuff.
Okay, after the train,
I saw that stuff in China is so cool.
So, I wanted to see
how many childs I can have in China
if I want to move there.
Statefamilyplanning.com
Look at that awesome view.
This is what you see from your room.
Okay, I'll stop here.
Okay, so what they are running.
Oh, Windows 2000.
I guess they know their shit.
Oh, yeah.
This is FTP-SMTP.
Well.
but dude,
he's already seeing the world with a server.
So, everybody from the world
can ask the same question
and get real-time answers.
Again, Nmap really failed
to differentiate between 2000 and me.
So, after I saw China is so damn cool,
I can have whatever child I want.
Yeah, sure.
I can buy my trailer, my truck.
I can buy a train.
I can buy my microphone cheap.
And I can have my favorite communist newspaper on the web.
I wanted to go to China so bad.
So, my last example.
If I wanted to go to China,
I need to get myself a visa, right?
So, I went to China for an office.
This is the English side
of the China Foreign Office,
which tells you what was there.
Yeah, we met with President Bush.
Yeah, it's so cool.
And we just had a visit
or Colin Powell would visit us
and blah, blah, blah
and a bunch of stuff
that really helps you get to China.
And they really update their website.
July 10.
Okay.
Leave them alone.
I guess they're running Windows 2000.
You want to see what ports are open?
Here you go.
Just as a reminder,
this is a byproduct of the Nmap scan.
The real cool thing is that I scanned it
with two packets, man.
Just to see the ports,
the NetBios SSN stuff.
Well, gee.
Don't we need updates from home?
And PC Anywhere.
You know, if someone really important comes to China
and we need to update it immediately.
I hope the admin will stay alive after this talk.
So, I guess my name will be up up front
on the list of the people
who will not visit China in the next couple of years.
And I will need to get a visa to get to China.
So, these were just port scans
and scans with my tool.
Just to show you up that
in order to get accurate results,
you don't need to puke on the network.
You can do it wisely.
Now, how wisely you can do that?
For the operating systems,
it is listing here.
One query, two queries,
three queries, four queries.
And the tool is just 0.0.1
without a failover mechanism.
So, I guess it's pretty cool.
What do I have to do next?
Or what do I have to implement?
And I'll do that fast.
I need to put some firewall to work.
More firewall checks, more firewall checks.
And I need to do the logic thing.
And I need to add DB support
and fingerprinting DB.
More logic, failovers, artificial intelligence.
And you saw that this is working, so...
Oh, well, what will happen with 0.0.2?
This is a no-person project.
In the next couple of days,
there will be a page stating
if you want to send me some information
or fingerprints about the stuff,
you want to show me,
or you want to donate hardware
because I have only two boxes.
And when installing 15 operating systems
in four hours to just check something,
it's not that nice.
If you'll go to my website,
you can go and download the tool.
This is the last thing I added
between Black Hat and DEF CON.
Everybody is doing host detection,
port scanning,
then OS fingerprinting,
and then exploiting.
This is dumb.
Why?
Because if I'm doing the OS fingerprinting in my style,
if, for example, I'm using Win2K
and I need to exploit IIS,
and I'm not endorsing it in any way,
no, really, so...
I can understand that I have Win2K in two packets.
And, for example, if I know what is my target,
for example, a web server,
I can send the exploit right away.
So in three or four packets,
I own the box.
And this is really cool
because with the other stuff
that is being done today,
you only scan to understand your operating system,
which you send a lot of packets,
and basically it's not still.
But if you do the opposite way,
using the stuff I showed you here,
three to four packets,
you own the box.
So just think about it.
Access is available from my website.
Soon,
there will be a page for Xprop on SourceForge.
It will be a daily CVS.
Well,
0.0.2 will be unreliable for a lot of time
until we'll stable it.
And it will be available from Fyodor Yerokhin's website as well.
So we'll have four mirrors for that.
The failover mechanism
was implemented by a simple nomad.
I didn't check, verified it until the end,
so I might write...
that part again.
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who was pressuring me to do the window thing,
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